1. Technical Field
This invention generally relates to the data processing field. More specifically, this invention relates to the location of object creation in object oriented systems.
2. Background Art
Since the dawn of the computer age, computer systems have evolved into extremely sophisticated devices, and computer systems may be found in many different settings. Computer systems typically include a combination of hardware, such as semiconductors and circuit boards, and software, also known as computer programs. As advances in semiconductor processing and computer architecture push the performance of the computer hardware higher, more sophisticated computer software has evolved to take advantage of the higher performance of the hardware, resulting in computer systems today that are much more powerful than just a few years ago.
Computer systems typically include operating system software that controls the basic function of the computer, and one or more software application programs that run under the control of the operating system to perform desired tasks. For example, a typical IBM Personal Computer may run the OS/2 operating system, and under the control of the OS/2 operating system, a user may execute an application program, such as a word processor. As the capabilities of computer systems have increased, the application software programs designed for high performance computer systems have become extremely powerful. Additionally, software development costs have continued to rise because more powerful and complex programs take more time, and hence more money, to produce.
One way in which the performance of application software programs has been improved while the associated development costs have been reduced is by using object oriented programming concepts. The goal of using object oriented programming is to create small, reusable sections of program code known as xe2x80x9cobjectsxe2x80x9d that can be quickly and easily combined and re-used to create new programs. This is similar to the idea of using the same set of building blocks again and again to create many different structures. The modular and re-usable aspects of objects will typically speed development of new programs, thereby reducing the costs associated with the development cycle. In addition, by creating and re-using a comprehensive set of well-tested objects, a more stable, uniform, and consistent approach to developing new computer programs can be achieved.
The Java programming language developed by Sun Microsystems is one modem object oriented programming language that has become very popular in recent years. From a programmer""s point of view, one of the advantages of the Java programming language is that memory allocation and reclamation are handled entirely by the run-time system, which relieves the programmer of the burden of determining how and when to destroy unneeded objects. All objects (other than those of primitive types) are allocated from a common xe2x80x9cheapxe2x80x9d, or section of memory. The garbage collection mechanism then monitors the objects in the heap, and periodically deletes unneeded objects, thereby reclaiming portions of the heap that are occupied by objects that can no longer be accessed from the user""s program.
One problem with the Java automatic allocation and reclamation of memory is that users have less control over their program""s performance. Each time an object is allocated, a certain cost is incurred as the memory manager updates its data structures. Furthermore, an additional cost must be paid to reclaim the object during garbage collection. Although these costs are small when considered individually, the sheer frequency of object allocation and reclamation result in a significant portion of program execution time being spend in the memory manager, allocating and reclaiming memory for objects.
Java""s memory management overhead is far greater than that of the C++ programming language, primarily because every Java object is allocated from the heap. In C++, programmers are given more control over the allocation of their objects. In particular, C++ programmers are able to declare objects to be local to a method. These objects come into existence when the method is invoked, and are automatically reclaimed when the method invocation terminates. Further, the run-time cost of allocating these objects is essentially zero, since they simply occupy space in the method""s invocation stack frame. Adding an object to the invocation stack frame simply means that the amount by which the stack pointer is moved must increase, but no additional instructions are required to do this. Compare this with Java, where every created object, no matter how small or how temporary, requires overhead from the run-time memory manager.
Recently, researchers in compiler technology have been working on ways to allocate some Java objects on a method""s stack frame, rather than going to the heap for each and every object, thereby improving on the performance of the native Java capabilities. In particular, if a compiler can automatically detect Java objects whose xe2x80x9clifetimesxe2x80x9d do not extend beyond the method in which they are created, these objects can be automatically allocated on the stack by the compiler rather than from the garbage-collected heap, resulting in improved performance. The technology used to determine which objects may be allocated on the stack is called xe2x80x9cescape analysisxe2x80x9d. The idea is to determine which objects have lifetimes that do not xe2x80x9cescapexe2x80x9d from the methods that create them. Escape analysis is presented in a paper by Choi et al., xe2x80x9cEscape Analysis for Javaxe2x80x9d, In Proceedings of the Conference on Object Oriented Programming, Systems, and Languages (OOPSLA), Denver, Colo. (November 1999), p. 1-19.
Escape analysis as described by Choi et al. generally allows allocating objects to a method""s stack if their lifetimes do not escape from their creating method. However, some types of objects, such as Java array objects, may have a size that is unknown at compile time, and therefore cannot be allocated to a method""s stack even if their lifetimes do not escape from their creating method. When an array object has an unknown size at compile time, the prior art allocates the array object from the heap. When an array object turns out to be small at run-time, the overhead associated with allocating the array object from the heap is a cost that must be incurred because there is no way in the prior art to stack-allocate array objects of unknown size at compile time. Without an apparatus and methods for allocating array objects of unknown size at compile time to a method""s call stack at run-time if the size of the array object is not excessive, the computer industry will continue to suffer undue performance limitations caused by allocating all Java array objects of unknown size at compile time from the heap.
According to the preferred embodiments, an object oriented mechanism and method allow allocating Java array objects of unknown size at compile time to a method""s invocation stack if the array""s size is less than a predetermined threshold value. Run-time code is generated that examines the actual size of the array object at run-time and that allocates the array object to the invocation stack at run-time if the size is less than a predetermined threshold value. In this manner Java array objects that have an unknown size at compile time may still be allocated to an invocation stack at run-time if the size of the object is sufficiently small.